The Internet is an ever growing collection of digital content. As it continues to grow, so too does the demand for the content. Users depend on the content for their news, entertainment, social networking, business, communications, etc. Efficient delivery of the content to the users is a continually changing problem.
To improve the user experience, content delivery networks (CDNs) have been established to decentralize and localize the distribution of the content to the user. Content from a content provider is distributed over a set of content servers of the CDN. The content servers are geographically positioned at high traffic locations of the data network.
When an end user submits a request for content from the content provider, the content provider responds by sending skeleton content back to the end user. The skeleton content may include a base HyperText Markup Language (HTML), Extensible Markup Language (XML), or Flash page with links to various embedded objects that populate the page with feature-rich content (e.g., videos and images). The embedded objects are hosted on various CDN content servers. The links to the embedded objects resolve to one or more of the CDN content servers that are determined to be closest to the end user. The end user then downloads the embedded objects from these CDN content servers. As a result, the end user downloads content from servers that are geographically closer than the content provider's servers which reduces overall latency and improves the user experience. The CDN further benefits the content provider by providing a cost-effective infrastructure that scales with increased demand without placing burden on the content provider's infrastructure.
Improvements are continually made to the CDN to more efficiently deliver content to the end users. However, the current structure of the Domain Name System (DNS) presents various barriers that have resulted in suboptimal workarounds and assumptions to be made when determining the content server that optimally distributes content to the end user.
FIG. 1 illustrates the DNS structure in order to illustrate these workarounds and assumptions. As shown, the DNS structure includes a recursive name server 110, root name server 120, high-level authoritative name server 130, and low-level authoritative name server 135. Also displayed are content servers 140 and 145 and end users 150 and 155 that are located in different regions 160 and 165.
The recursive name server 110 is located in the first region 160. End user 150 is also located in the first region 160 and is configured to contact the recursive name server 110 to resolve various Internet Protocol (IP) addresses (e.g., 123.456.789.012) from domain names (e.g., www.example.com). End user 155 is located in a second region 165, but is configured to contact the recursive name server 110 in the first region 160 to resolve various IP addresses from domain names. The recursive name server 110 may be a corporate name server that is located in New York and the end user 155 may be an end user of the corporation that is located in a satellite Los Angeles office.
When either of the end users 150 and 155 attempts to resolve an IP address (e.g., www.example.com), a DNS query is sent to the recursive name server 110. In this simplified figure, the recursive name server 110 recursively resolves the IP address from the root to the high-level domain (i.e., example.com) to the low-level domain (i.e., www.example.com). Accordingly, a first DNS query is made from the recursive name server 110 to the root name server 120 to resolve the IP address for www.example.com. The root name server 120 responds to the recursive name server 110 with the IP address for the high-level authoritative name server 130 (i.e., “.com” server). A second DNS query is made from the recursive name server 110 to the high-level authoritative name server 130 to resolve the IP address for www.example.com. The high-level authoritative name server 130 responds to the recursive name server 110 with the IP address for the low-level authoritative name server 135 (i.e., “example.com” server). A third DNS query is made from the recursive name server 110 to the low-level authoritative name server 135 to resolve the IP address for www.example.com. The low-level authoritative name server 135 responds to the recursive name server 110 with the IP address for the content server 140. The recursive name server 110 returns the IP address of the content server 140 to the end users 150 and 155 after which each end user 150 and 155 contacts the content server 140 to download content (e.g., embedded objects).
The low-level authoritative name server 135 identifies the content server 140 by identifying the content server that is geographically closest to the recursive name server 110. In many instances, the low-level authoritative name server 135 makes this determination based on the IP address of the recursive name server 110 since the IP address of the recursive name server 110 is included within the DNS query to the low-level authoritative name server 135.
When a CDN or other provider of content relies on such DNS operation in order to identify content servers, the CDN makes an important assumption that any end users contacting the recursive name server 110 are located in the same region 160 as the recursive name server 110. However, this assumption may be false in some cases when an end user (i.e., end user 155) contacts a remote recursive name server that is located in a different region than the end user. Consequently, the end user ends up receiving content from a content server of a CDN that does not optimally distribute content to the end user relative to other content servers of the CDN.
Accordingly, there is a need to better optimize the routing of end users to content servers. There is a need to remove assumptions as to the locations of the end users in order to more accurately identify the servers that optimally distribute content to the end users. Moreover, the determination from which to identify the optimal servers should include other metrics in addition to or instead of geographic proximity as the closest content server may not optimally deliver content when compared to more distant content servers.